1. Field of the Invention
This invention generally relates to method of debugging, and more particularly, to instrumentation (i.e. debugging) of software executable programs during runtime in a multiprocessing environment.
2. Description of the Related Art
Debugging is a methodical process of finding and reducing a number of bugs or defects a computer program, thus making it behave as expected. Debugging tends to be harder when various subsystems are tightly coupled, as changes in one may cause bugs to emerge in another.
Generally, debugging a program is a cumbersome and tiring task. The debugging skill of a programmer is probably the biggest factor in the ability to debug a problem, but the difficulty of software debugging varies greatly with the programming language used and the available tools, such as debuggers. Debuggers are software tools which enable programmer to monitor the execution of a program, stop it, re-start it, run it in slow motion, more importantly change values in memory and even, in some cases go back in time by reversing the execution order of program instructions, which is sometimes referred to as “rolling back”.
To get debugging information during runtime, developers adopt to use a dynamic tracing mechanism, referred to as dynamic instrumentation, typically inserting breakpoints, also referred to as probes, during runtimes at various paths, collecting the relevant data from the breakpoints and continuing normal execution without disrupting the execution of the program. Inserting breakpoints is typically a method used by programmers wherein a breakpoint is placed at a point of interest in a program, replacing an original instruction(s) and trace data is collected in a breakpoint handle when program execution reaches the breakpoint. The breakpoint instruction is replaced by the original instruction(s), execution is single stepped, and after single stepping the original instructions is again replaced by the breakpoint instruction.
Typically in an uniprocess environment and all instances of breakpoints are traced successfully. In a multiprocessor environment, breakpoints are sometimes missed for example on threads running the same instructions on different processors, where one thread hits the breakpoint and single steps on the original instruction while another may execute the replaced original instruction. A disadvantage is that in a multiprocessor environment, such breakpoints seem to be missed on one processor while some other processors single steps on the original instructions, thereby missing some instances.
For example, consider a program to add two numbers, wherein a program is a sequence of instructions. Accordingly, the following four program to add two numbers:
Get a first number1: get AGet a second number2: get BAdd two numbers3: add A, BPrint result of addition4: print resultThis program might require debugging at step 3 to verify the inputs provided to the program by inserting a breakpoint instruction at step 3. The original instruction is copied into an allocated memory location and the original instruction is replaced with the breakpoint instruction. When the breakpoint is encountered, the program generates an exception. The debugger removes the breakpoint instruction, puts the original instruction back in the program and executes it there, and inserting the breakpoint instruction back for next execution cycle.
However, when multiple threads run the same program, a first thread “A” executed the addition program and the breakpoint is hit. When the breakpoint instruction is removed and original instruction is inserted back, the program appears as
1: get A
2: get B
3: break-here
4: print result
where the original instruction address was “add A,B”. Therefore, before the breakpoint instruction is inserted back for the next execution cycle, there is a window where some other thread “B” executing the same program fails to notice or encounter the breakpoint instruction. Hence, when the same program is being executed by thread B, there will not be any exception generated and there will not be any opportunity to save the debugging information, thereby missing the information in thread B.
Therefore there is a need for improved instrumentation for multiprocessing environments, preferably dynamic instrumentation, and without a way to improve instrumentation, the promise of this technology may never be fully achieved.